This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/service/service.test.ts
Line: 834-890

Comment:
**Real-time path not covered by the new test**

The new test exercises only the log-replay path (via `mockConvertStoredEntriesToEvents`). The real-time path — where `handleSessionEvent` receives the `run_started` `AcpMessage` directly and calls `updatePromptStateFromEvents` — is not tested. If the handler in `updatePromptStateFromEvents` were accidentally removed or broken, no test would catch it.

A second `it` case (or parameterised variant) that calls `handleSessionEvent` with a crafted `run_started` `AcpMessage` and asserts `updateSession` is called with `{ status: "connected" }` would close this gap.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/SessionView.tsx
Line: 602-613

Comment:
**Tooltip precedence when both `handoffInProgress` and `!isAgentReady` are true**

When `handoffInProgress` is `true` and `isAgentReady` is also `false`, `submitDisabledExternal` will be `true` but the tooltip will say "Waiting for agent to be ready…" rather than a handoff-related message. If `PromptInput` shows the `submitTooltipOverride` unconditionally when non-undefined, the user sees a potentially misleading message. Worth verifying whether these two conditions are mutually exclusive in practice, or if handoff tooltip priority should be explicit.

How can I resolve this? If you propose a fix, please make it concise.

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/service/service.test.ts
Line: 469-474

Comment:
**Fragile timing-based negative assertion**

This test waits a hard-coded 100 ms and then asserts `updateSession` was *never* called. If the async hydration callback takes longer (slow CI, high load), the assertion races past before the call happens and the test passes for the wrong reason.

A more reliable pattern is to wait on a positive side-effect that proves hydration completed (e.g. `vi.waitFor(() => expect(mockTrpcLogs.writeLocalLogs.mutate).toHaveBeenCalled())`) and only then check the negative:

```ts
// Wait for hydration to finish via a side-effect we know runs after the
// run_started handler (e.g. the log-write that happens unconditionally).
await vi.waitFor(() =>
  expect(mockTrpcLogs.writeLocalLogs.mutate).toHaveBeenCalled(),
);
expect(mockSessionStoreSetters.updateSession).not.toHaveBeenCalledWith(
  "run-123",
  { status: "connected" },
);
```

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: apps/code/src/renderer/features/sessions/components/mergeConversationItems.ts
Line: 193-199

Comment:
**Content-based dedup can suppress a legitimate follow-up with the same text**

While `optimisticItems` is non-empty, *every* `user_message` in `conversationItems` whose `content` matches the optimistic set is filtered — not just the first echo. If the user sends a second message with the exact same wording as the seeded optimistic item (e.g. task description "build me a thing" submitted again), its echo would also be silently removed from the view.

This window is narrow (only while the initial optimistic item persists), so it mainly matters if `clearOptimisticItems` / `replaceOptimisticWithEvent` is not called promptly once the first `session/prompt` echo lands. Worth verifying the cloud session has a reliable path to drain `optimisticItems` after the first echo is confirmed.

How can I resolve this? If you propose a fix, please make it concise.